fix: reject path template holes that share a segment with literal text#132
Merged
Conversation
PathTemplate.parse never required a {hole} to sit at a "/" boundary, so
a literal prefix or suffix sharing a path segment with a hole (e.g.
"/reports/{id}.json" or "v{version}") got silently re-segmented when
the URL was built: BindingExecutor's appendTokenSegments splits every
Literal token on "/" and adds every Hole token as its own segment,
independent of whether they were adjacent in the template.
@PathTemplate documents itself as a "Go-style path template", and
net/http.ServeMux wildcards must occupy a full path segment, so fail
fast at parse time instead: a hole whose neighboring literal doesn't
carry a "/" at the shared edge is now rejected with KuriBindException.
Adjacent holes with no literal between them (e.g. "{a}{b}") are still
allowed, since neither can be split.
Closes #82
The "hole must occupy a whole path segment" rule previously exempted a
hole from the boundary check whenever it abutted another hole, on the
theory that neither side could be split. But the composer always emits
one full segment per hole regardless of adjacency, so a template like
"{a}{b}" silently composed as two separate path segments even though
its spelling implies a single merged one. Treat two adjacent holes the
same as a hole abutting literal text: they now require a "/" between
them, and only a true template boundary (start/end of string) is
exempt.
Every template string in the existing suite starts with a literal (usually
a leading "/"), so isBoundedBefore's null-predecessor branch — a hole
sitting as the very first token, e.g. "{id}/detail" — was never exercised.
The symmetric end-of-template case was already covered via the catch-all
test. Add a test that parses "{id}/detail" and asserts it succeeds with
tokens [Hole("id"), Literal("/detail")], isolating the previously-untested
branch.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PathTemplate.parsenever required a{hole}to sit at a/boundary, so a literal prefix or suffix sharing a path segment with a hole (e.g./reports/{id}.jsonorv{version}) got silently re-segmented when the URL was built:BindingExecutor'sappendTokenSegmentssplits everyLiteraltoken on/and adds everyHoletoken as its own segment, regardless of whether it was adjacent to literal text in the template.@PathTemplateframes itself as a "Go-style path template", andnet/http.ServeMuxwildcards must occupy a full path segment, so the fix rejects a boundary violation at parse time (fail fast) rather than trying to keep same-segment literal/hole runs together during composition. A hole is still allowed to sit directly against another hole with no literal between them ({a}{b}), since neither side can be split.@PathTemplateKDoc.Test plan
./gradlew :kuri-bind:jvmTest— added regression tests reproducing both issue examples (/reports/{id}.jsonwithid=5,v{version}withversion=2) at both thePathTemplate.parselevel and end-to-end throughBindingExecutor; confirmed they failed before the fix and pass after../gradlew :kuri-bind:ktlintCheck./gradlew :kuri-bind:detekt./gradlew :kuri-bind:apiCheck(no public API shape change —kuri-bindis JVM-only, so nojsNodeTest/native leg applies here)Closes #82